Reissuing obligations to preserve privacy

ABSTRACT

A system is provided for reissuing obligations whose ownership is recorded in a distributed ledger to preserve the identity of prior owners of the obligations. The system accesses a target transaction in which an issuer has a target obligation to a target owner specified in the target transaction. The target transaction has one or more ancestor transactions that each specify an owner. The system retires the target transaction so that the issuer no longer has the target obligation. The system then receives an indication that the issuer created a reissue transaction in which the issuer has a reissued obligation to the target owner that is specified in the reissue transaction. The reissue transaction does not have any ancestor transactions.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a divisional of U.S. patent application Ser. No.16/693,771, filed Nov. 25, 2019, entitled “REISSUING OBLIGATIONS TOPRESERVE PRIVACY,” which is a divisional of U.S. patent application Ser.No. 15/799,930, filed Oct. 31, 2017, entitled “REISSUING OBLIGATIONS TOPRESERVE PRIVACY,” the entire disclosure of each of these applicationsis incorporated herein by reference.

BACKGROUND

The bitcoin system was developed to allow electronic cash to betransferred directly from one party to another without going through afinancial institution, as described in the white paper entitled“Bitcoin: A Peer-to-Peer Electronic Cash System” by Satoshi Nakamoto. Abitcoin (e.g., an electronic coin) is represented by a chain oftransactions that transfers ownership from one party to another party.To transfer ownership of a bitcoin, a new transaction is generated andadded to a stack of transactions in a block. The new transaction, whichincludes the public key of the new owner, is digitally signed by theowner with the owner's private key to transfer ownership to the newowner, as represented by the new owner public key. Once the block isfull, the block is “capped” with a block header that is a hash digest ofall the transaction identifiers within the block. The block header isrecorded as the first transaction in the next block in the chain,creating a mathematical hierarchy called a “blockchain.” To verify thecurrent owner, the blockchain of transactions can be followed to verifyeach transaction from the first transaction to the last transaction. Thenew owner need only have the private key that matches the public key ofthe transaction that transferred the bitcoin. The blockchain creates amathematical proof of ownership in an entity represented by a securityidentity (e.g., a public key), which in the case of the bitcoin systemis pseudo-anonymous.

To ensure that a previous owner of a bitcoin did not double-spend thebitcoin (i.e., transfer ownership of the same bitcoin to two parties),the bitcoin system maintains a distributed ledger of transactions. Withthe distributed ledger, a ledger of all the transactions for a bitcoinis stored redundantly at multiple nodes (i.e., computers) of ablockchain network. The ledger at each node is stored as a blockchain.In a blockchain, the transactions are stored in the order that thetransactions are received by the nodes. Each node in the blockchainnetwork has a complete replica of the entire blockchain. The bitcoinsystem also implements techniques to ensure that each node will storethe identical blockchain, even though nodes may receive transactions indifferent orderings. To verify that the transactions in a ledger storedat a node are correct, the blocks in the blockchain can be accessed fromoldest to newest, generating a new hash of the block and comparing thenew hash to the hash generated when the block was created. If the hashesare the same, then the transactions in the block are verified. Thebitcoin system also implements techniques to ensure that it would beinfeasible to change a transaction and regenerate the blockchain byemploying a computationally expensive technique to generate a nonce thatis added to the block when it is created. A bitcoin ledger is sometimesreferred to as an Unspent Transaction Output (“UTXO”) set because ittracks the output of all transactions that have not yet been spent.

Although the bitcoin system has been very successful, it is limited totransactions in bitcoins or other cryptocurrencies. Efforts arecurrently underway to use blockchains to support transactions of anytype, such as those relating to the sale of vehicles, sale of financialderivatives, sale of stock, payments on contracts, and so on. Suchtransactions use identity tokens, which are also referred to as digitalbearer bonds, to uniquely identify something that can be owned or canown other things. An identity token for a physical or digital asset isgenerated using a cryptographic one-way hash of information thatuniquely identifies the asset. Tokens also have an owner that uses anadditional public/private key pair. The owner public key is set as thetoken owner identity, and when performing actions against tokens,ownership proof is established by providing a signature generated by theowner private key and validated against the public key listed as theowner of the token. A person can be uniquely identified, for example,using a combination of a user name, social security number, andbiometric (e.g., fingerprint). A product (e.g., refrigerator) can beuniquely identified, for example, using the name of its manufacturer andits serial number. The identity tokens for each would be a cryptographicone-way hash of such combinations. The identity token for an entity(e.g., person or company) may be the public key of a public/private keypair, where the private key is held by the entity. Identity tokens canbe used to identify people, institutions, commodities, contracts,computer code, equities, derivatives, bonds, insurance, loans,documents, and so on. Identity tokens can also be used to identifycollections of assets. An identity token for a collection may be acryptographic one-way hash of the digital tokens of the assets in thecollection. The creation of an identity token for an asset in ablockchain establishes provenance of the asset, and the identity tokencan be used in transactions (e.g., buying, selling, insuring) of theasset stored in a blockchain, creating a full audit trail of thetransactions.

To record a simple transaction in a blockchain, each party and assetinvolved with the transaction needs an account that is identified by adigital token. For example, when one person wants to transfer a car toanother person, the current owner and next owner create accounts, andthe current owner also creates an account that is uniquely identified bythe car's vehicle identification number. The account for the caridentifies the current owner. The current owner creates a transactionagainst the account for the car that indicates that the transaction is atransfer of ownership, indicates the public keys (i.e., identity tokens)of the current owner and the next owner, and indicates the identitytoken of the car. The transaction is signed by the private key of thecurrent owner, and the transaction is evidence that the next owner isnow the current owner.

To enable more complex transactions than bitcoin can support, somesystems use “smart contracts.” A smart contract is computer code thatimplements transactions of a contract. The computer code may be executedin a secure platform (e.g., an Ethereum platform, which provides avirtual machine) that supports recording transactions in blockchains. Inaddition, the smart contract itself is recorded as a transaction in theblockchain using an identity token that is a hash (i.e., identity token)of the computer code so that the computer code that is executed can beauthenticated. When deployed, a constructor of the smart contractexecutes, initializing the smart contract and its state. The state of asmart contract is stored persistently in the blockchain. When atransaction is recorded against a smart contract, a message is sent tothe smart contract, and the computer code of the smart contract executesto implement the transaction (e.g., debit a certain amount from thebalance of an account). The computer code ensures that all the terms ofthe contract are complied with before the transaction is recorded in theblockchain. For example, a smart contract may support the sale of anasset. The inputs to a smart contract to sell a car may be the identitytokens of the seller, the buyer, and the car and the sale price in U.S.dollars. The computer code ensures that the seller is the current ownerof the car and that the buyer has sufficient funds in their account. Thecomputer code then records a transaction that transfers the ownership ofthe car to the buyer and a transaction that transfers the sale pricefrom the buyer's account to the seller's account. If the seller'saccount is in U.S. dollars and the buyer's account is in Canadiandollars, the computer code may retrieve a currency exchange rate,determine how many Canadian dollars the seller's account should bedebited, and record the exchange rate. If either transaction is notsuccessful, neither transaction is recorded.

When a message is sent to a smart contract to record a transaction, themessage is sent to each node that maintains a replica of the blockchain.Each node executes the computer code of the smart contract to implementthe transaction. For example, if 100 nodes each maintain a replica of ablockchain, then the computer code executes at each of the 100 nodes.When a node completes execution of the computer code, the result of thetransaction is recorded in the blockchain. The nodes employ a consensusalgorithm to decide which transactions to keep and which transactions todiscard. Although the execution of the computer code at each node helpsensure the authenticity of the blockchain, it requires large amounts ofcomputer resources to support such redundant execution of computer code.

Although blockchains can effectively store transactions, the largeamount of computer resources, such as storage and computational power,needed to maintain all the replicas of the blockchain can beproblematic. To overcome this problem, some systems for storingtransactions do not use blockchains, but rather have each party to atransaction maintain its own copy of the transaction. One such system isthe Corda system developed by R3, Ltd., which provides a decentralizeddistributed ledger platform in which each participant in the platformhas a node (e.g., computer system) that maintains its portion of thedistributed ledger. When parties agree on the terms of a transaction, aparty submits the transaction to a notary, which is a trusted node, fornotarization. The notary maintains an UTXO database of unspenttransaction outputs. When a transaction is received, the notary checksthe inputs to the transaction against the UTXO database to ensure thatthe outputs that the inputs reference have not been spent. If the inputshave not been spent, the notary updates the UTXO database to indicatethat the referenced outputs have been spent, notarizes the transaction(e.g., by signing the transaction or a transaction identifier with apublic key of the notary), and sends the notarization to the party thatsubmitted the transaction for notarization. When the party receives thenotarization, the party stores the notarization and provides thenotarization to the counterparties.

In many industries, one entity is contractually obligated to provide acertain quantity of an item or asset to another entity. For example, abank may, in exchange for payment, create an obligation to pay a certainamount of money to a customer who has funds on deposit with the bank tocover the obligation. The bank issues a transaction that is recorded ina distributed ledger specifying that the customer is the owner of theobligation. The customer can then transfer that obligation to anotherentity, such as a supplier who supplies products to the customer of thebank. To transfer the obligation to the supplier, another transactionthat references the issuing transaction is recorded in the distributedledger specifying that the obligation is now owned by the supplier. Thesupplier can then tender the obligation to the bank for payment,assuming the obligation is payable on demand. The supplier couldalternatively transfer the obligation to another party or split theobligation by recording multiple transactions that each transferownership of part of the original obligation. Each of those transactionswould reference the transaction that transfers the obligation to thesupplier. In addition, if the supplier is the owner of multipleobligations from the same bank, the supplier could combine theobligations into a single obligation by recording a transaction thatreferences the multiple obligations.

A transaction needs to reference its input transactions so that thenotary can make a determination of whether the outputs of the inputtransactions have been consumed or spent. Also, a party can follow thereferences to input transactions of the transaction to check whether theinput transactions were performed correctly, follow the references tothose input transactions of the input transactions to check whetherthose input transactions were performed correctly, and so on until atransaction is encountered with no input transactions (i.e., atransaction corresponding to the issuance of an obligation). Becausetransactions reference prior transactions, information about the priorowner of an obligation could be derived by accessing those priortransactions. For example, each transaction may include the public keyof the owner. If a party has previously dealt with that owner, the partymay know the public key of the owner and can thus identify the owner.Even if the party cannot identify an owner, the party may be able toglean other information such as how much money is paid to a supplier,what the profit made by a supplier is, and so on.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating transactions including a transfertransaction and a reissue transaction.

FIG. 2A illustrates flow diagrams of the processing of an owner andissuer to reissue an obligation in some embodiments.

FIG. 2B illustrates flow diagrams of alternate processing of an ownerand issuer to reissue an obligation in some embodiments.

FIG. 3 is a block diagram that illustrates components of the RO systemin some embodiments.

FIG. 4 is a flow diagram that illustrates processing of a reissueobligations component of an owner node in some embodiments.

FIG. 5 is a flow diagram that illustrates the processing of a retrieveancestor transactions component of an owner node in some embodiments.

FIG. 6 is a flow diagram that illustrates the processing of a reissuecomponent of an owner node in some embodiments.

FIG. 7 is a flow diagram that illustrates the processing of a proposereissue component of an owner node in some embodiments.

FIG. 8 is a flow diagram that illustrates the processing of a processissue proposal component of an owner node in some embodiments.

FIG. 9 is a flow diagram that illustrates the processing of an issueobligation component of an issuer node in some embodiments.

FIG. 10 is a flow diagram that illustrates processing of a processreissue proposal component of an issuer node in some embodiments.

FIG. 11 is a flow diagram that illustrates the processing of an exchangeconfidential identities component of a CI system in some embodiments.

FIG. 12 is a flow diagram that illustrates the processing of a proposetransaction component of the CI system in some embodiments.

DETAILED DESCRIPTION

A method and system are provided for reissuing obligations, whoseownership is transferred via transactions recorded in a distributedledger, to provide privacy for prior owners of obligations. In someembodiments, a reissue obligation (“RO”) system is provided that allowsa target obligation to be retired and then reissued so that the priorowners (e.g., identified by their public keys) of the target obligationcannot be identified from the reissued obligation. The distributedledger stores a target transaction that identifies a target obligationsuch as that the issuer is obligated to provide a quantity of an asset(e.g., money or a commodity) to the current owner identified in thetarget transaction in accordance with the terms of the targetobligation. For example, the target obligation may be that the issuer isobligated to deliver 500,000 shares of stock of company A to the currentowner of the obligation on a certain date. The target transaction may belinked to a chain of ancestor transactions that split, combine, ortransfer obligations resulting in the target obligation represented bythe target transaction.

In some embodiments, when the target obligation is to be reissued, thecurrent owner may generate a signed transfer transaction that names theissuer as the new owner of the target obligation. The current owner thensends the signed transfer transaction to the issuer with an indicationthat the target obligation is to be reissued. After confirming thevalidity of the signed transfer transaction, the issuer signs thetransfer transaction and forwards it to the notary. Upon receiving thenotarized transfer transaction, the issuer records the notarizedtransfer transaction in the distributed ledger and sends it to thenow-prior owner of the target obligation. The issuer may also generate asigned reissue transaction indicating that the prior owner of the targetobligation is the current owner of the reissue obligation with the samequantity of the asset as the target obligation and may send the signedreissue transaction to its current owner (i.e., the now-prior owner ofthe target obligation). An issue or reissue transaction may not need tobe notarized because the signature of the issuer may be sufficient toensure the validity of the issue or reissue transaction.

In other embodiments, when the target obligation is to be reissued, thecurrent owner of the target obligation as specified by the targettransaction may send to the issuer a proposal to reissue the targetobligation as a reissued obligation via a reissue transaction with noancestor transactions. In response, the issuer may send to the currentowner a proposed transfer transaction (signed by the issuer) to transferownership of the target obligation to the issuer, which would retire thetarget obligation. The current owner then signs the transfertransaction, coordinates the notarizing of the transfer transaction, andsends the notarized transfer transaction to the issuer. Upon receivingthe notarized transfer transaction, the issuer sends to the owner(formerly the current owner, now the previous owner) of the targetobligation a reissue proposal to reissue the target obligation as areissued obligation with the same quantity and same terms as the nowretired target obligation. The previous owner then sends a signedproposed reissue transaction to the issuer specifying that the previousowner of the target transaction is to be the current owner of thereissued obligation. Upon receiving the proposed reissue transaction,the issuer signs the reissue transaction, coordinates the notarizing ofthe reissue transaction, sends the notarized reissue transaction to thenow current owner and records the notarized reissue transaction. Uponreceiving the notarized reissue transaction, the current owner of thereissued obligation records the notarized transaction in the distributedledger.

Because there are no prior owners of the reissued obligation, thereissue transaction does not reference any ancestor transactions. Thus,a party that has access to the reissue transaction cannot identify anyprior owners (e.g., via public keys of the prior owners) of the targetobligation given the reissue transaction. Thus, the privacy of the priorowners of the target obligation is preserved by reissuing the targetobligation as a reissued obligation. Although an issuer may not receivea direct benefit (e.g., payment) for reissuing an obligation, issuersmay have an incentive to support the reissuing of obligations as aservice that would make dealing with the issuer more attractive to itscustomers and potential customers. In addition, the reissuing ofobligations may allow for transactions in obligations to be verifiedmore efficiently because the number of ancestor transactions that needto be checked can be greatly reduced. Indeed, if every transfer inownership from the current owner to the next owner automaticallyincludes a transfer transaction to the issuer and a reissue transactionwith the next owner as the current owner of the reissued obligation,then there are no ancestor transactions that need to be verified. As aresult, the computational resources needed to transfer obligations canbe greatly reduced as communications between nodes to retrieve ancestortransactions can be avoided, verification of the correctness of ancestortransactions can be avoided, and so on. In addition, the privacy ofprior owners of obligations is preserved.

As described above, the retiring of a target obligation and the issuingof the reissued obligation is not performed as an atomic operation. Forexample, an untrusted issuer could accept the transfer transaction butrefuse to issue the reissued obligation. In such a case, the issuerwould have retired the target obligation to its benefit without issuingthe reissued obligation to the prior owner's detriment. So the RO systemas described above is premised on the issuer of an obligation beingtrusted. In some embodiments, the notary may support notarizing acompound retire transaction involving a transfer transaction and areissue transaction. In such a case, both the issuer and the currentowner of the target obligation sign a compound transaction that includesthe signed transfer transaction and the signed reissue transaction, eachof which indicates that it is part of a compound transaction but doesnot identify the other transaction. After its verification processes(e.g., check for already consumed input states), the notary notarizesboth the transfer transaction and the reissue transaction or neither.When both are notarized, the notary returns the notarized transactionsto the party (i.e., the issuer or current owner of the reissuedobligation) who sent the compound transaction. The party may then sendthe notarized transactions to the counterparty, or the issuer may sendthe notarized transactions to both parties. Thus, the retire transactioncan be performed via an atomic operation. If a party tries to have thetransfer transaction or the reissue transaction notarized, the notarywill refuse to do so because the transaction itself identifies that itis part of a compound transaction and may include a hash of the othertransaction.

As described above, the RO system is used with a distributed ledger thatis not a blockchain, and thus a notary is used to check for consumedinput states and to notarize transactions. In some embodiments, the ROsystem can be used with a distributed ledger that is a blockchain. Forexample, the RO system may be used to reissue obligations whosetransactions are recorded in a public or private Ethereum blockchain. Insuch a case, a smart contract may support a reissue message toautomatically reissue an obligation in compliance with the terms definedby the issuer and the original owner of the obligation. Also, asdescribed above, the current owner of the target obligation initiatesthe reissue process. Alternatively, the issuer could initiate thereissue process. Also, the responsibility for proposing both thetransfer transaction and the reissue transaction can be that of theissuer or that of the current owner, or the responsibility may be splitso that the issuer proposes one transaction and the current ownerproposes the other transaction.

In some embodiments, the RO system may employ a reissue criterion todetermine when to reissue obligations. For example, the RO system mayretrieve all the ancestor transactions of a target transaction and thenanalyze the ancestor transactions to determine whether the reissuecriterion is satisfied. The reissue criterion may specify a certainnumber of ancestor transactions, a certain path length of ancestortransactions, a certain number of direct ancestors of an ancestortransaction, and so on. The RO system may check for the reissuecriterion while ancestor transactions are being retrieved and, if thereissue criterion is satisfied, terminate the retrieving of additionalancestor transactions. Each issuer and owner may define their ownreissue criterion. In some embodiments, any transfer of an obligationmay need to be approved by the issuer. For example, an issuer may berequired by law to prohibit transfer of an obligation to certainparties. In such a case, the issuer must be aware of all transfers ofits obligation and can apply the reissue criterion to identify theobligations that should be reissued. A distributed ledger network mayalso have a network-wide reissue criterion defined for the network. If atransaction satisfies the network-wide reissue criterion, then thetransaction is considered to be frozen in that it cannot be used asinput to another transaction, except as input to a transfer transactiontransferring ownership of the underlying obligation to the issuer. Inthis way, it can be ensured that the transactions of the network complywith the requirements of the network as specified by the reissuecriterion. Although the reissue criterion is described primarily basedon number or path length of ancestor transactions, other reissuecriteria can be used. For example, the reissue criterion may factor intiming of the transactions, issuer of the transactions, value of thetransactions, and so on.

In some embodiments, a target obligation may be only partially reissued.For example, if the target obligation is for 500,000 shares of stock,then the transfer transaction may specify 200,000 shares and thereissued obligation would be for 200,000 shares. The target transactionmay be left unchanged, but the notary may record that 200,000 shareshave been consumed. Alternatively, a new, descendant transaction of thetarget transaction may be created for an obligation of 300,000 shares.

In some embodiments, the identities of parties to a transaction can bekept confidential by generating confidential identities that are knownonly to the parties of the transaction and that may be unique to thattransaction. A “party A” may have a well-known identity (e.g., “partyA,” a personal name, or a company name) that is certified by awell-known identity certificate WKI.C_(A) issued by a certificateauthority. To have a certificate issued, party A provides their publickey WKI.pub_(A) of their WKI.pub_(A)/WKI.priv_(A) key pair and theiridentity or name (e.g., “party A”) to the certificate authority. Thecertificate authority verifies that the requesting party is really partyA. The verification can be whatever the certificate authority and usersof the certificates deem is appropriate to prove that the requestingparty is really party A. When verified, the certificate authority issuesthe well-known identity certificate WKI.C_(A) for party A. Thewell-known identity certificate includes the public key WKI.pub_(A) andthe name WKI.name_(A) of party A and is signed with the private keyWKI.priv_(CA) of the certificate authority. The WKI.priv_(CA) of thecertificate authority is kept secret by the certificate authority. Aparty who is presented with a public key pub and WKI.C_(A) can verifythat pub is the public key of party A identified by the WKI.name_(A) byverifying using WKI.pub_(CA) that WKI.C_(A) was signed by thecertificate authority and comparing pub to WKI.pub_(A).

Although the party A can use WKI.pub_(A) as its identifier in varioustransactions, anyone with access to WKI.C_(A), which may be widelypublished, can determine that WKI.name_(A) is the identity associatedwith WKI.pub_(A). To help preserve the confidentiality of parties, aconfidential identity (“CI”) system allows for the generating ofconfidential identities that can be verified by confidential identitycertificates issued by the parties themselves or by others on behalf ofthe parties. To create a confidential identity for party A, party Acreates a public/private key pair CI.pub_(A)/CI.priv_(A). Party A thencreates a confidential identity certificate CI.C_(A) with the public keyCI.pub_(A) and the name CI.name_(A) that is signed using WKI.priv_(A).Party A can then use CI.pub_(A) as their identifier in a transactionwith another party such as party B. Party A can provide CI.C_(A) toparty B as proof of the identity of CI.pub_(A). Party B, who also hasaccess to WKI.C_(A) can use WKI.pub_(A) to check the signature ofWCI.C_(A) and know that CI.pub_(A) is a confidential identifier forparty A as identified by WKI.name_(A). Party A could alternativelyprovide only CI.pub_(A) signed by WKI.pub_(A) to party B along with anasserted identity, rather than CI.C_(A), as party B can use the assertedidentity to retrieve the WKI.C_(A) and verify the signature onCI.pub_(A). Party A may use a different confidential identity for eachtransaction so that an entity cannot ascertain that the same party wasinvolved in the various transactions.

FIG. 1 is a diagram illustrating transactions including a transfertransaction and a reissue transaction. Blocks 101-109 each represent atransaction. Block 110 illustrates the contents of a transaction. Eachtransaction includes the public key of the current owner and is signedby the private key of the previous owner. Each transaction identifies anobligation that includes an issuer, type of asset, and quantity of theasset. A transaction, other than one for a newly issued obligation,includes the identification of inputs to the transaction. The input to atransaction identifies the ancestor transaction and an output of theancestor transaction. Transaction 101 represents a newly issuedtransaction for an obligation with a quantity of $100 that is owned byowner O₁, transaction 102 represents a newly issued transaction for anobligation with a quantity of $50 that is owned by owner O₂, andtransaction 103 represents a newly issued transaction for an obligationwith a quantity of $75 that is owned by owner O₃. Transaction 104represents a transfer of the obligation of the transaction 101 to a newowner O₂. Transaction 101 is an ancestor transaction of transaction 104,and transaction 104 is a descendent transaction of transaction 101.Transaction 104 includes a reference to transaction 101 as input totransaction 104. Transaction 105 represents a transfer of theobligations of transactions 102 and 104 with a combined quantity of $150to a new owner O₃. Transaction 105 includes a reference to bothtransactions 102 and 104 as ancestor transactions. Transaction 105represents a combining of the obligations of transactions 102 and 104.Transaction 106 represents a transfer of a portion—$100—of theobligation of transaction 105 to owner O₅. Transaction 107 represents atransfer of a portion—$50—of the obligation of transaction 105 and atransfer of the obligation of transaction 103 to owner O₄, resulting inthe combined obligation of $125. Transactions 106 and 107 represent asplit of the obligation of transaction 105. Transfer transaction 108 andreissue transaction 109 represent the reissuing of the obligation oftransaction 107. The owner O₄ may initiate the reissuing of theobligation of transaction 107 by creating a transfer transaction 108that transfers the obligation of transaction 107 to the issuer. Theowner O₄ then creates the reissue transaction 109 with the sameobligation—$125—as that of transaction 107. Reissue transaction 109 doesnot reference any ancestor transactions. As such, someone cannotidentify owners O₁, O₂, or O₃ of prior transactions to transaction 108from reissue transaction 109. The reissuing of the obligation results inthe identity of these owners being preserved.

FIG. 2A illustrates flow diagrams of the processing of an owner andissuer to reissue an obligation in some embodiments. An owner component210 of the RO system illustrates the processing of the owner, and anissuer component 220 illustrates the processing of the issuer. In block221, the issuer issues an obligation to an owner that is represented byan issue transaction. The obligation may be transferred through variousparties and ultimately to the owner by recording transactions in thedistributed ledger. In block 211, the owner component accepts thetransaction, transferring the obligation to the owner. The owner at somepoint decides to have the obligation reissued to protect the privacy ofprior owners. In block 212, the owner component transfers ownership ofthe obligation to the issuer to retire the obligation. In block 222, theissuer component accepts the transfer of ownership and responds to theowner. In block 213, the owner component then sends a reissue request tothe issuer. In block 223, the issuer component reissues the obligation,represented by a reissue transaction recorded in the distributed ledger,and then completes. In block 214, the owner component accepts thereissue transaction and completes.

FIG. 2B illustrates flow diagrams of alternate processing of an ownerand issuer to reissue an obligation in some embodiments. An ownercomponent 230 of the RO system illustrates the processing of the owner,and an issuer component 240 illustrates the processing of the issuer. Inblock 241, the issuer issues an obligation to an owner that isrepresented by an issue transaction. The obligation may be transferredthrough various parties and ultimately to the owner by recordingtransactions in the distributed ledger. In block 231, the ownercomponent accepts the transaction transferring the obligation to theowner. The owner at some point decides to have the obligation reissuedto protect the privacy of prior owners. In block 232, the ownercomponent transfers ownership of the obligation to the issuer to retirethe obligation by sending a transfer transaction to the issuer. In block242, the issuer component accepts the transfer transaction (e.g., afterthe notary notarizes it), generates a reissue transaction, sends thereissue transaction to the owner, and then completes. In block 233, theowner component receives and records the reissue transaction, which maynot need to be notarized because the issuer's signature may besufficient to establish validity. The owner component then completes.

FIG. 3 is a block diagram that illustrates components of the RO systemin some embodiments. The RO system includes components used by an issuernode 310 and an owner node 320. The issuer node and owner node mayinterface with notary 330, other issuer nodes 340, and other owner nodes350 via communications channel 360. In addition to having components forinterfacing with other nodes, an issuer node may include an issueobligation component 311 and a process reissue proposal component 312,along with a transaction store 316. The issue obligation component isresponsible for issuing obligations. The process reissue proposalcomponent is responsible for processing reissue requests received fromowner nodes. The transaction store stores the transactions of theissuer. The owner node includes a reissue obligations component 321, aretrieve ancestor transactions component 322, a reissue component 323, apropose reissue component 324, and a process issue proposal component325, along with a transaction store 326. The reissue obligationscomponent is responsible for coordinating the reissue obligations andinvokes the retrieve ancestor transactions component to determinewhether a reissue criterion is satisfied. If a reissue criterion issatisfied, the reissue component is invoked to reissue a transaction.The reissue component invokes the propose reissue component tocoordinate the reissuing of the obligation. The process issue proposalcomponent is invoked when an issue proposal is received from an issuer,whether for an original obligation or a reissue obligation. Thetransaction store stores the transactions of the owner. The issuer nodes340 include components similar to the issuer node 310, and the ownernodes 350 include components similar to the owner node 320.

The computing systems (e.g., network nodes or collections of networknodes) on which the RO system and the CI system may be implemented mayinclude a central processing unit, input devices, output devices (e.g.,display devices and speakers), storage devices (e.g., memory and diskdrives), network interfaces, graphics processing units, cellular radiolink interfaces, global positioning system devices, and so on. The inputdevices may include keyboards, pointing devices, touch screens, gesturerecognition devices (e.g., for air gestures), head and eye trackingdevices, microphones for voice recognition, and so on. The computingsystems may include desktop computers, laptops, tablets, e-readers,personal digital assistants, smartphones, gaming devices, servers, andso on. The computing systems may access computer-readable media thatinclude computer-readable storage media and data transmission media. Thecomputer-readable storage media are tangible storage means that do notinclude a transitory, propagating signal. Examples of computer-readablestorage media include memory such as primary memory, cache memory, andsecondary memory (e.g., DVD) and other storage. The computer-readablestorage media may have recorded on them or may be encoded withcomputer-executable instructions or logic that implements the RO systemand the CI system. The data transmission media are used for transmittingdata via transitory, propagating signals or carrier waves (e.g.,electromagnetism) via a wired or wireless connection. The computingsystems may include a secure cryptoprocessor as part of a centralprocessing unit for generating and securely storing keys and forencrypting and decrypting data using the keys.

The RO system and the CI system may be described in the general contextof computer-executable instructions, such as program modules andcomponents, executed by one or more computers, processors, or otherdevices. Generally, program modules or components include routines,programs, objects, data structures, and so on that perform tasks orimplement data types of the RO system and the CI system. Typically, thefunctionality of the program modules may be combined or distributed asdesired in various examples. Aspects of the RO system and the CI systemmay be implemented in hardware using, for example, anapplication-specific integrated circuit (“ASIC”) or field programmablegate array (“FPGA”).

FIG. 4 is a flow diagram that illustrates processing of a reissueobligations component of an owner node in some embodiments. A reissueobligations component 400 is invoked to determine whether to reissueobligations of the owner and coordinate their reissuance. In block 401,the component selects the next transaction of the transaction store thathas not yet been fully consumed. In decision block 402, if all suchtransactions have already been selected, then the component completes,else the component continues at block 403. In block 403, the componentinvokes a retrieve ancestor transactions component, passing anindication of the selected transaction, to retrieve the ancestortransactions for the selected transaction. In block 404, the componentanalyzes the ancestor transactions to determine whether the issuecriterion is satisfied for the selected transaction. In decision block405, if the reissue criterion is satisfied, then the component continuesat block 406, else the component loops to block 401 to select the nexttransaction. In block 406, the component invokes the reissue component,passing an indication of the selected transaction, to reissue theobligation of the selected transaction. The component then loops toblock 401 to select the next transaction

FIG. 5 is a flow diagram that illustrates the processing of a retrieveancestor transactions component of an owner node in some embodiments. Aretrieve ancestor transactions component 500 is passed an indication ofa transaction and identifies all ancestor transactions. In block 501,the component selects the next input transaction that is a directancestor transaction of the passed transaction. In decision block 502,if all such input transactions have already been selected, then thecomponent returns, else the component continues at block 503. In block503, the component retrieves the selected input transaction from thedistributed ledger. In block 504, the component stores the selectedinput transaction mapped to the passed transaction as an ancestortransaction. In decision block 505, if the selected input transaction isan issue transaction with no ancestors, then the component continues atblock 507, else the component continues at block 506. In block 506, thecomponent recursively invokes the retrieve ancestor transactionscomponent passing an indication of the selected input transaction toidentify its ancestor transaction and then loops to block 501 to selectthe next input transaction of the passed transaction. In block 507, thecomponent stores an indication of the issuer and then returns.

FIG. 6 is a flow diagram that illustrates the processing of a reissuecomponent of an owner node in some embodiments. A reissue component 600is passed an indication of a target transaction and coordinates thereissue of the target transaction. In block 601, the component retrievesan indication of the issuer of the target transaction. In decision block602, if the issuer supports reissuing of transactions, then thecomponent continues at block 603, else the component completes. Thedetermination of whether an issuer supports the reissuing oftransactions generally or this target transaction in particular can bemade in various ways. For example, the target transaction may include aflag signed by the issuer, the issuer may publicize whether it supportsreissuing transactions, a message may be sent to the issuer askingwhether it supports the reissuing of this target transaction, and so on.In block 603, the component invokes a propose reissue transaction of theowner node passing an indication of the transaction. In block 604, thecomponent receives a reissue proposal from the issuer. In block 605, thecomponent invokes the process issue proposal component, passing anindication of the reissue proposal, and then completes.

FIG. 7 is a flow diagram that illustrates the processing of a proposereissue component of an owner node in some embodiments. A proposereissue component 700 is invoked, passing an indication of a targettransaction whose target obligation is to be reissued. In block 701, thecomponent creates a reissue proposal that identifies the targettransaction. In block 702, the component sends the reissue proposal tothe issuer. In block 703, the component receives from the issuer atransfer transaction to transfer ownership of the obligation to theissuer to retire the obligation. In decision block 704, if the componentverifies that the transfer transaction is correct, then the componentcontinues at block 705, else the component reports an error. In block705, the component coordinates the notarizing of the transfertransaction by interacting with the notary node. In block 706, thecomponent sends the notarized transfer transaction to the issuer asevidence that the transfer has been completed. In block 707, thecomponent stores the notarized transfer transaction in the transactionstore of the owner node. Alternatively, as discussed above, when thetarget obligation is transferred to the issuer, the issuer may simplycreate and sign the reissue transaction and send it to the owner node.In such a case, the owner node would not need to explicitly propose thereissue transaction. Also, the reissue transaction may not need to benotarized because it has no input transactions whose outputs might havealready been consumed.

FIG. 8 is a flow diagram that illustrates the processing of a processissue proposal component of an owner node in some embodiments. A processissue proposal component 800 is invoked to process an issue proposalreceived from an issuer. The issue proposal can be for the issuance of anew obligation or reissuance of a target obligation that is beingretired. In block 801, the component verifies that the issue proposal isacceptable. In decision block 802, if the issue proposal is verified asacceptable, then the component continues at block 803, else thecomponent reports an error. In block 803, the component sends a signedissue transaction to the issuer. In block 804, the component receivesthe notarized issue transaction from the issuer. In decision block 805,if the notarized issue transaction is verified, then the componentcontinues at block 806, else the component reports an error. In block806, the component stores the notarized issue transaction in thetransaction store of the owner node and then completes.

FIG. 9 is a flow diagram that illustrates the processing of an issueobligation component of an issuer node in some embodiments. An issueobligation component 900 is invoked, passing an indication of anobligation and the owner of the obligation. The component issues anobligation, which may be a reissued obligation. In block 901, thecomponent sends a proposal for the issuance to the owner. In block 902,the component receives the signed issuance transaction from the owner.In decision block 903, if the received issuance transaction can beverified, then the component continues at block 904, else the componentreports an error. In block 904, the component signs the issuancetransaction with a signature of the issuer. In block 905, the componentsends the signed issuance transaction to the notary. In block 906, thecomponent receives the notarized issuance transaction from the notary.In block 907, the component sends the notarized issuance transaction tothe owner. In block 908, the component stores the notarized issuancetransaction in the transaction store of the issuer node and thencompletes.

FIG. 10 is a flow diagram that illustrates processing of a processreissue proposal component of an issuer node in some embodiments. Aprocess reissue proposal component 1000 receives a reissue proposal andcoordinates the reissuing of the target obligation indicated by theproposal. In block 1001, the component verifies the target transactionof the proposal. In decision block 1002, if the target transaction isverified, the component continues at block 1003, else the componentreports an error. In block 1003, the component creates a signed transfertransaction to transfer the target obligation to the issuer to retirethe target obligation. In block 1004, the component sends the signedtransfer transaction to the owner. The owner may be the owner specifiedin the target transaction or may be a different owner to whom the targetobligation is to be transferred as part of the reissuance. In block1005, the component receives a notarized transfer transaction from theowner. In block 1006, the component stores the notarized transfertransaction in the transaction store of the owner node. In block 1007,the component invokes the issue obligation component to issue thereissue obligation in the name of the owner and then completes.

FIG. 11 is a flow diagram that illustrates the processing of an exchangeconfidential identities component of a CI system in some embodiments. Anexchange confidential identities component 1100 is invoked for a party Ato exchange their confidential identity with the confidential identityof a party B. In block 1101, the component generates aCI.pub_(A)/CI.priv_(A) key pair. In block 1102, the component generatesa confidential identity certificate CI.C_(A) with the public keyCI.pub_(A) and the name CI.name_(A) that is signed using WKI.priv_(A).In block 1103, the component generates and sends to party B a noncen_(A) and receives from party B a nonce n_(B). The nonces may helpensure that the confidential identities are from and intended for theother party. In block 1104, the component generates a signed hash S^(A)by signing using CI.priv_(A) a hash of the confidential identitycertificate CI.C_(A) combined with a hash of nonces n_(A) and n_(B). Inblock 1105, the component sends the signed hash S^(A) and theconfidential identity certificate CI.C_(A) to party B and receives thesigned hash S^(B) and the confidential identity certificate CI.C_(B)from party B. In block 1106, the component decrypts the signed hashS^(B) using CI.pub_(B). In block 1107, the component verifies theconfidential identity certificate CI.C_(B) using WKI.pub_(B) to ensurethat it was signed by party B. In block 1108, the component verifiesthat the decrypted hash of S^(B) matches the hash of the certificateCI.C_(B) combined with a hash of nonces n_(A) and n_(B). In decisionblock 1109, if the verifications are successful, then the componentcontinues at block 1110, else the component reports an error. In block1110, the component stores the confidential identity certificateCI.C_(B) and then completes.

FIG. 12 is a flow diagram that illustrates the processing of a proposetransaction component of the CI system in some embodiments. A component1200 is invoked to propose a transaction and to provide the identity ofa party to the transaction identifies the parties by their confidentialidentities. In block 1201, the component sends to parties B and C atransaction proposed by party A. The proposed transaction identifies theparties by their confidential identities. Party A has received theconfidential identity certificate CI.C_(B) from party B and theconfidential identity certificate CI.C_(C) from party C. Party A mayhave also provided its confidential identity certificate CI.C_(A) toparty B and party C. Party C, however, does not have the confidentialidentity certificate CI.C_(B) and thus cannot identify party B from thepublic key CI.pub_(B) specified in the proposed transaction. Party C mayneed to know the identity of party B, for example, because of the lawsof the governing jurisdiction. In block 1202, the component receives arequest from party C for the confidential identity certificate CI.C_(B)of party B so that party C can determine the identity of party B. Inblock 1203, the component retrieves the confidential identitycertificate CI.C_(B) that was stored in block 1110. In block 1204, thecomponent sends the confidential identity certification CI.C_(B) toparty C. Party C can then use the name CI.name_(B) of the confidentialidentity certificate CI.C_(B) to retrieve the well-known certificateWKI.C_(B). Party C can then verify the signature of confidentialidentity certificate CI.C_(B) using the public key WKI.pub_(B) to ensurethat confidential identity certificate CI.C_(B) was generated by party Band thus CI.name_(B) and WKI.name_(B) represent the identity of party B.

The following paragraphs describe various embodiments of aspects of theRO system and the CI system. An implementation of the RO system and theCI system may employ any combination of the embodiments. The processingdescribed below may be performed by a computing device with a processorthat executes computer-executable instructions stored on acomputer-readable storage medium that implements the RO system.

In some embodiments, a method performed by one or more computing systemsis provided for reissuing an obligation. The method accesses a targettransaction that represents a target obligation of an issuer. The targettransaction identifies a quantity of an asset of the target obligationand a first entity as current owner of the target obligation. The issueris obligated to provide the quantity of the asset to the current ownerin accordance with terms of the target obligation. The targettransaction identifies an ancestor transaction that was consumed whencreating the target transaction. An identifier of a second entityspecified as then-owner of the target obligation in the ancestortransaction can be determined given the target transaction. The methodcreates a transfer transaction of the target transaction that transfersownership of the target obligation to the issuer to retire the targetobligation. The transfer transaction identifies the target transaction.The method receives from the issuer an indication that a reissuetransaction was created that represents a reissued obligation of theissuer. The reissue transaction identifies the quantity of the asset ofthe reissued obligation and the first entity as current owner of thereissued obligation. The reissue transaction does not identify anyancestor transactions so that the identifier of the second entity cannotbe determined from the reissue transaction. In some embodiments, thetransactions are recorded in a blockchain. In some embodiments, thetransactions are recorded in a distributed ledger that is not ablockchain. In some embodiments, the method further, prior to creatingthe transfer transaction, analyzes any ancestor transactions of thetarget transaction to determine whether a reissue criterion issatisfied. In some embodiments, the method further analyzes transactionsto identify one or more target transactions to reissue. In someembodiments, the method further sends a reissue request to the issuerthat identifies the transfer transaction. When the reissue requestidentifies a third entity, the reissue transaction identifies the thirdentity as current owner of the reissued obligation and the identifier ofthe first entity and the second entity cannot be determined from thereissue transaction. In some embodiments, a transaction specifies a typeof the asset. In some embodiments, the asset is fungible. In someembodiments, the reissue transaction specifies a quantity of the assetof the reissued obligation that is less than the quantity specified bythe target obligation.

In some embodiments, a method performed by one or more computing systemsis provided for reissuing an obligation. The method accesses a targettransaction in which an issuer has a target obligation to a target ownerspecified in the target transaction. The target transaction has one ormore ancestor transactions that each specify an owner. The methodretires the target transaction so that the issuer no longer has thetarget obligation. The method receives an indication that the issuercreated a reissue transaction in which the issuer has a reissuedobligation to the target owner that is specified in the reissuetransaction. The reissue transaction does not any ancestor transactions.In some embodiments, the retiring of the target transaction includescreating a transfer transaction that transfers ownership of the targetobligation to the issuer. In some embodiments, the target obligationspecifies a quantity of an asset and the retiring of the targettransaction creates a first transfer transaction that transfersownership of a portion of the quantity of the target obligation to theissuer and a second transfer transaction that transfers ownership of theremaining portion of the quantity of the target obligation to an ownerdifferent from the issuer. In some embodiments, the method, prior toretiring the target transaction, analyzes one or more ancestortransactions of the target transaction to determine whether a reissuecriterion is satisfied. In some embodiments, the method further analyzestransactions to identify one or more target transactions to reissue.

In some embodiments, a method performed by one or more computing systemsis provided for reissuing an obligation. The method issues obligationsby an issuer. The issuing of an obligation includes creating atransaction that specifies an owner of the obligation. The methodreceives a request to reissue a target obligation of an issuer. Therequest identifies a transfer transaction that specifies that the issueris the owner of the target obligation and that specifies the prior ownerof the target obligation. The method creates a reissue transaction inwhich the issuer has a reissued obligation to the prior owner that isspecified in the reissue transaction. The reissue transaction does nothave any ancestor transactions. In some embodiments, each obligationspecifies a quantity of an asset and the reissued obligation is for thesame quantity as the target obligation. In some embodiments, eachobligation specifies a quantity of an asset and the reissued obligationis for a quantity less than the quantity of the target obligation. Insome embodiments, the transfer transaction specifies a targettransaction whose output is input to the transfer transaction and thatidentifies an owner of the target obligation of the target transaction,and the target transaction specifies a further input transaction whoseoutput is input to the target transaction and that specifies an owner ofthe further input transaction. In some embodiments, an owner isspecified by a public key.

In some embodiments, a computing system is provided for reissuing anobligation. The computing system includes one or more computer-readablestorage mediums storing computer-executable instructions and one or moreprocessors for executing the computer-executable instructions stored inthe one or more computer-readable storage mediums. The instructionscontrol the computing system to access a target transaction in which anissuer has a target obligation to a target owner specified in the targettransaction. The instructions control the computing system to retire thetarget transaction so that the issuer no longer has the targetobligation. The instructions also control the computing system toreceive an indication that the issuer has created a reissue transactionin which the issuer has a reissued obligation to the target owner thatis specified in the reissue transaction. In some embodiments, theinstructions that retire the target transaction create a transfertransaction that transfers ownership of the target obligation to theissuer. In some embodiments, the target obligation specifies a quantityof an asset and the instructions that retire the target transactioncreate a first transfer transaction that transfers ownership of aportion of the quantity of the target obligation to the issuer and asecond transfer transaction that transfers ownership of the remainingportion of the quantity of the target obligation to an owner differentfrom the issuer. In some embodiments, the target transaction specifies aprior transaction, and the reissue transaction does not specify a priortransaction.

In some embodiments, a method performed by one or more computing systemsis provided for providing a confidential identity for an entity. Themethod generates a confidential public/private key pair. The methodgenerates a confidential certificate for the confidential identity. Theconfidential certificate includes the confidential public key and awell-known name of the entity. The method signs the confidentialcertificate with a well-known public key of the entity. The method sendsthe signed confidential certificate to another party. In someembodiments, the method further receives a nonce from the other entity,generates a nonce, sends the generated nonce to the other entity, signsreceived nonce and the sent nonce, and sends the signed nonces to theother entity. In some embodiments, the signing of the confidentialcertificate and the signing of the nonce are performed by a signing of acombination of the confidential certificate and the nonces. In someembodiments, the method further receives a signed confidentialcertificate from the other party. The method further verifies using awell-known public key of the other party that the received signedconfidential certificate was signed by the other party. The method alsofurther stores the received confidential certificate for use inidentifying the other party from the confidential public key of thereceived confidential certificate.

Although the subject matter has been described in language specific tostructural features and/or acts, it is to be understood that the subjectmatter defined in the appended claims is not necessarily limited to thespecific features or acts described above. Rather, the specific featuresand acts described above are disclosed as example forms of implementingthe claims. Accordingly, the invention is not limited except as by theappended claims.

We claim:
 1. A method performed by one or more computing system forverifying a confidential identity of a first entity, the methodcomprising: accessing a signed first confidential identity certificateof the first entity that includes a first confidential public key of thefirst entity and a first well-known name of the first entity and that issigned using a first well-known private key of the first entity, thefirst confidential public key and a first confidential private keycomposing a first confidential public/private key; a first well-knownpublic key and the first well-known private key composing a firstwell-known public/private key pair; and verifying using the firstwell-known public key that the signed first confidential identitycertificate was signed using the first well-known private key.
 2. Themethod of claim 1 further comprising: accessing signed data that issigned using the first confidential private key; and verifying, usingthe first confidential public key, that the data was signed using thefirst confidential public key.
 3. The method of claim 1 furthercomprising: receiving from the first entity a first nonce; and sendingto the first entity a second nonce; wherein the signed firstconfidential identity certificate is part of a signed hash derived basedon the signed first confidential identity certificate, the first nonce,and the second nonce.
 4. The method of claim 3 wherein the verifyingfurther verifies that signed hash is derived based on the first nonceand the second nonce.
 5. The method of claim 1 further comprising:receiving a second confidential public key and signed data that issigned using a second confidential private key and; and verifying, usingthe second confidential public key, that the data was signed using thesecond confidential private key.
 6. The method of claim 5 wherein thesigned data is a transaction to which a second entity is a party, thetransaction including the second confidential public key.
 7. The methodof claim 5 wherein multiple first confidential identity certificates aregenerated for signing different data.
 8. The method of claim 1 whereinthe signed first confidential public key is signed in combination withan identifier of the first entity wherein the signed combination forms afirst confidential identity certificate.
 9. The method of claim 2wherein the data is a transaction that identifies the first entity bythe first confidential public key.
 10. The method of claim 9 whereinoutput of the transaction is input to another transaction to which thefirst entity is a party.
 11. At least one non-transitory,computer-readable medium carrying instructions, which when executed byat least one data processor, performs operations for verifying aconfidential identity of a first entity, the operations comprising:accessing a signed first confidential identity certificate of the firstentity that includes a first confidential public key of the first entityand a first well-known name of the first entity and that is signed usinga first well-known private key of the first entity, the firstconfidential public key and a first confidential private key composing afirst confidential public/private key; a first well-known public key andthe first well-known private key composing a first well-knownpublic/private key pair; and verifying using the first well-known publickey that the signed first confidential identity certificate was signedusing the first well-known private key.
 12. The computer-readable mediumof claim 11 further comprising: receiving signed data that is signedusing the first confidential private key; and verifying, using the firstconfidential public key, that the data was signed using the firstconfidential public key.
 13. The computer-readable medium of claim 11,wherein the operations further comprise: receiving from the first entitya first nonce; and sending to the first entity a second nonce; whereinthe signed first confidential identity certificate is part of a signedhash derived based on the signed first confidential identitycertificate, the first nonce, and the second nonce.
 14. Thecomputer-readable medium of claim 13 wherein the verifying furtherverifies that signed hash is derived based on the first nonce and thesecond nonce.
 15. One or more computing systems for verifying anidentity of a first entity, the one or more computing system comprising:one or more computer-readable storage mediums for storingcomputer-executable instructions for controlling the one or morecomputing systems to: access a signed first confidential public key ofthe first entity and that is signed using a first well-known private keyof the first entity, the first confidential public key and a firstconfidential private key composing a first confidential public/privatekey, a first well-known public key and the first well-known private keycomposing a first well-known public/private key pair; verify using thefirst well-known public key that the signed first confidential publickey was signed using the first well-known private key; access signeddata that is data that is signed using the first confidential privatekey; and verify that the first entity signed the data using the signedfirst confidential public key; and one or more processors for executingthe computer-executable instructions stored in the one or morecomputer-readable storage mediums.
 16. The one or more computing systemsof claim 15 wherein the signed first confidential public key is signedin combination with an identifier of the first entity wherein the signedcombination forms a first confidential identity certificate.
 17. The oneor more computing systems of claim 16 wherein the instructions further:receive from the first entity a first nonce; and send to the firstentity a second nonce, wherein the signed first confidential public keyis part of a signed hash derived based on the first nonce and the secondnonce, the first confidential identity certificate being received aspart of receiving the signed hash.
 18. The one or more computing systemsof claim 17 wherein the verifying further verifies that signed hash isderived based on the first nonce and the second nonce.
 19. The one ormore computing systems of claim 15 wherein the data is a transactionthat identifies the first entity by the first confidential public key.20. The one or more computing systems of claim 19 wherein output of thetransaction is input to another transaction to which the first entity isa party.